Analysing Inconsistent Specifications

In previous work we advocated continued development of specifications in the presence of inconsistency. To support this we presented quasi-classical (QC) logic for reasoning with inconsistent specifications. The logic allows the derivation of non-trivial classical inferences from inconsistent information. In this paper we present a development called labelled QC logic, and some associated analysis tools, that allows the tracking and diagnosis of inconsistent information. The results of analysis are then used to guide further development in the presence of inconsistency. We illustrate the logic and our tools by specifying and analysing parts of the London Ambulance Service. We argue that the scalability of our approach is made possible by deploying the ViewPoints framework for multi-perspective development, such that our analysis tools are only used on partial specifications of a manageable size. 1. Motivation and Background Inconsistent specifications are an inevitable intermediate product of a requirements engineering process. Inconsistencies may arise because of the preliminary nature of elicited requirements, or indeed because of inherently conflicting customer needs (for example, because of multiple, conflicting views that these customers hold on a problem or solution domain). A desirable product of a requirements engineering process is a formal specification which captures customer requirements. The formality of such a specification is desirable because it is amenable to formal reasoning and analysis which, in turn, also facilitate the validation of customer requirements. The process of translating informal (often vague and inconsistent) requirements statements into a precise formal (consistent) specification is a difficult one. We believe that tools which enable reasoning and analysis of inconsistent, but formal, specifications can help improve such a translation process. In this paper, we present some formal, light-weight, logic-based tools that can provide a requirements engineer with a handle on inconsistencies in specifications. The aim of these tools is to provide additional “non-intrusive” reasoning in the presence of inconsistency and simple analysis of inconsistent information. Such reasoning and analysis can in turn provide guidance to the requirements engineer on what course of action to take in the presence of certain inconsistencies (we still believe, however, that such action is ultimately a human-driven process). The “non-intrusive” operation of such tools is necessary because in many instances, the logic-based tools are computationally intensive and would otherwise render automated tool support unusable. The work presented here complements our previous work on eliciting requirements from multiple perspectives using “ViewPoints” [11, 12, 25], and develops our approach of inconsistency handling in this setting [16]. Our motivation is that inconsistencies are inevitable in software development (and requirements engineering) processes and products. They provide a focus for further development (e.g., requirements elicitation), and can be regarded as “desirable” in that they highlight issues that need further attention. As such, they should be tolerated, analysed and acted upon in other words, systematically managed [23]. The focus of this paper is a logic-based approach to managing inconsistent specifications. In particular, we focus on an adaptation of classical logic (termed quasiclassical, or QC, logic) that allows limited reasoning in the presence of inconsistency (§3), and extend it in simple ways that facilitate the analysis of inconsistent specifications (§4). We then develop an example to illustrate our logical tools (§5) based on the IWSSD-8 case study of the “London Ambulance Service” [15], and discuss the impact of the kind of analysis we advocate on our goal of inconsistency handling and management. We conclude with a short discussion on the role of automated tool support, and related and future work (§6 and §7). A more detailed discussion is available in [20]. 2. Requirements: From fuzzy to formal The requirements of many large software systems are characterised by imprecision. Customers often underor over-specify their requirements, and requirements statements are often contradictory. However, in order to elicit customer requirements effectively it is essential that the needs of all stakeholders are captured. To this end we have used the ViewPoints framework for multiperspective development to explicitly represent different stakeholder requirements [25]. In moving towards a precise specification that we can validate and then satisfy, there also is the need for some formal reasoning and analysis. We have found classical logic to be an appealing form of formal representation because it allows the capture of a wide range of development information, and has an existing body of tools and technology for analysis and reasoning; e.g., [1], [6] . Unfortunately, a large body of requirements information, elicited during the early part of the requirements engineering cycle, is inconsistent, and therefore there is a need to reason with inconsistent information. Classical logic, however, is trivialised in the presence of inconsistency; that is, by the definition of the logic, any inference follows from inconsistent information (ex falso quodlibet). Formally, { α, Qα } o β To address this problem, we developed a quasi-classical (QC) logic that allows non-trivial reasoning in the presence of inconsistency. 3. QC Logic: Reasoning in the presence of